Addition of compile configuration using the new Intel LLVM compilers ifx and icx for Fortran and C code, respectively

TYPE: enhancement

KEYWORDS: Intel, LLVM, oneAPI, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Addressing issue wrf-model#1884 for Intel oneAPI ifx/icx builds

Solution:
Add configuration to configure.defaults mirroring original Intel ifort/icc build with minor tweaking

ISSUE: For use when this PR closes an issue.
Fixes wrf-model#1884

LIST OF MODIFIED FILES:
M arch/configure.defaults

TESTS CONDUCTED:
1. WRF Core em_real compiles with ifx/icx (see attached log).
2. It does not impact other parts of the code.

RELEASE NOTE:
Added build configuration for new Intel oneAPI LLVM ifx/icx compilers, which will be available on NCAR's new computer, Derecho.

…nd-dependent hydrometeor retrieval. (wrf-model#1920)

A background-dependent hydrometeor retrieval scheme for indirect radar reflectivity assimilation

TYPE: New feature

KEYWORDS: Reflectivity assimilation, hydrometeor retrieval

SOURCE: Haiqin Chen (Nanjing University); Tao Sun (NCAR)

DESCRIPTION OF CHANGES:
Problem:
In the original WRFDA use_radar_rhv scheme, the proportion of the snow and graupel is a fixed value that is measured by the ratio of coefficients for snow and graupel. In that case, the same snow mixing ratio and graupel mixing ratio are retrieved from reflectivity data.

Solution:
A background-dependent hydrometer retrieval and assimilation scheme is added to assimilate hydrometeors from reflectivity data. In this new scheme, the proportion of each hydrometeor from reflectivity data is diagnosed from background microphysical states. With this scheme, the contribution of each hydrometeor species to the reflectivity varies widely
in different reflectivity ranges and different heights. Therefore, the retrieved hydrometeors are more reasonable, and better hydrometeor analysis can be obtained from reflectivity assimilation.
References:
Chen, H., Gao, J., Wang, Y., Chen, Y., Sun, T., Carlin, J. and Zheng, Y., 2021. Radar reflectivity data assimilation method based on background‐dependent hydrometeor retrieval: Comparison with direct assimilation for real cases. Quarterly Journal of the Royal Meteorological Society, 147(737), pp.2409-2428.
Chen, H., Chen, Y., Gao, J., Sun, T. and Carlin, J.T., 2020. A radar reflectivity data assimilation method based on background-dependent hydrometeor retrieval: An observing system simulation experiment. Atmospheric research, 243, p.105022.

LIST OF MODIFIED FILES: list of changed files (use `git diff --name-status master` to get formatted list)
M. Registry/registry.var
M. var/da/da_radar/da_radar.f90
M. var/da/da_radar/da_get_innov_vector_radar.inc

TESTS CONDUCTED: 
1. The codes are successfully compiled in Chyenne using the intel fortran.
1. Single-time reflectivity assimilation has been tested in Cheyenne and reasonable results are obtained.

TYPE: new feature

KEYWORDS: lightning data, vertical velocity, pseudo divergence, pseudo water vapor

SOURCE: Zhixiong Chen (zchen@fjnu.edu.cn, Fujian Normal University, China)

DESCRIPTION OF CHANGES:
A new lightning data assimilation scheme has been implemented in the WRFDA. In this lightning DA scheme, the lightning flash rate is first converted to the maximum vertical velocity using an empirical relationship and then expanded to profiles of vertical velocities. The profiles of vertical velocity can be directly assimilated with the control variable of W. Another way is to assimilate pseudo divergence converted from vertical velocity to adjust the Kinematic states. A scheme to assimilate pseudo water vapor retrievals from lightning flash rate observations is also added. In the humidity assimilation scheme, the mixing ratio profiles of pseudo water vapor are retrieved from the locations where a rapid increase in lightning flash rate is detected. 

LIST OF MODIFIED FILES: 
M       Registry/registry.var
M       frame/module_driver_constants.F
M       var/build/da.make
M       var/build/depend.txt
M       var/da/da_control/da_control.f90
M       var/da/da_define_structures/da_allocate_observations.inc
M       var/da/da_define_structures/da_allocate_y.inc
A       var/da/da_define_structures/da_allocate_y_lightning.inc
M       var/da/da_define_structures/da_deallocate_observations.inc
M       var/da/da_define_structures/da_deallocate_y.inc
M       var/da/da_define_structures/da_define_structures.f90
M       var/da/da_define_structures/da_zero_y.inc
A       var/da/da_lightning/da_ao_stats_lightning.inc
A       var/da/da_lightning/da_calculate_grady_lightning.inc
A       var/da/da_lightning/da_check_max_iv_lightning.inc
A       var/da/da_lightning/da_div_profile.inc
A       var/da/da_lightning/da_div_profile_adj.inc
A       var/da/da_lightning/da_div_profile_tl.inc
A       var/da/da_lightning/da_get_innov_vector_lightning.inc
A       var/da/da_lightning/da_jo_and_grady_lightning.inc
A       var/da/da_lightning/da_lightning.f90
A       var/da/da_lightning/da_oi_stats_lightning.inc
A       var/da/da_lightning/da_print_stats_lightning.inc
A       var/da/da_lightning/da_residual_lightning.inc
A       var/da/da_lightning/da_transform_xtoy_lightning.inc
A       var/da/da_lightning/da_transform_xtoy_lightning_adj.inc
M       var/da/da_main/da_wrfvar_top.f90
M       var/da/da_minimisation/da_calculate_grady.inc
M       var/da/da_minimisation/da_calculate_residual.inc
M       var/da/da_minimisation/da_get_innov_vector.inc
M       var/da/da_minimisation/da_get_var_diagnostics.inc
M       var/da/da_minimisation/da_jo_and_grady.inc
M       var/da/da_minimisation/da_minimisation.f90
M       var/da/da_minimisation/da_write_diagnostics.inc
M       var/da/da_obs/da_fill_obs_structures.inc
A       var/da/da_obs/da_fill_obs_structures_lightning.inc
M       var/da/da_obs/da_obs.f90
M       var/da/da_obs/da_obs_sensitivity.inc
M       var/da/da_obs/da_transform_xtoy.inc
M       var/da/da_obs/da_transform_xtoy_adj.inc
M       var/da/da_obs_io/da_final_write_obs.inc
M       var/da/da_obs_io/da_obs_io.f90
M       var/da/da_obs_io/da_read_iv_for_multi_inc.inc
A       var/da/da_obs_io/da_read_obs_lightning.inc
M       var/da/da_obs_io/da_read_omb_tmp.inc
A       var/da/da_obs_io/da_scan_obs_lightning.inc
M       var/da/da_obs_io/da_search_obs.inc
M       var/da/da_obs_io/da_write_iv_for_multi_inc.inc
M       var/da/da_obs_io/da_write_obs.inc
M       var/da/da_setup_structures/da_setup_obs_structures.inc
M       var/da/da_setup_structures/da_setup_obs_structures_ascii.inc
A       var/da/da_setup_structures/da_setup_obs_structures_lightning.inc
M       var/da/da_setup_structures/da_setup_structures.f90
M       var/da/da_statistics/da_analysis_stats.inc
M       var/da/da_statistics/da_statistics.f90
M       var/da/da_test/da_check_xtoy_adjoint.inc
A       var/da/da_test/da_check_xtoy_adjoint_lightning.inc
M       var/da/da_test/da_get_y_lhs_value.inc
M       var/da/da_test/da_test.f90

TESTS CONDUCTED: 
1. Tested it with 3DVar on Cheyenne using the intel compiler.

RELEASE NOTE: 
A lightning data assimilation scheme has been added to assimilate pseudo vertical velocity, divergence fields, or water vapor retrievals from lightning flash rate data.
Chen, Z., Sun, J., Qie, X., Zhang, Y., Ying, Z., Xiao, X., & Cao, D. (2020). A method to update model kinematic states by assimilating satellite-observed total lightning data to improve convective analysis and forecasting. Journal of Geophysical Research: Atmospheres, 125, e2020JD033330. https://doi.org/10.1029/2020JD033330

Bugfix for the lightning DA

TYPE: bug fix

DESCRIPTION OF CHANGES:
There are some bugs in the [PR#1962](wrf-model#1962), which is fixed in this PR.

LIST OF MODIFIED FILES:
M   var/da/da_minimisation/da_get_var_diagnostics.inc
M   var/da/da_statistics/da_analysis_stats.inc

TESTS CONDUCTED: 
1. Tested using the GNU compiler on Derecho.

Removal of redundant code files wrf_status_codes.h, wrf_io_flags.h, io_int_idx_tags.h

…ilently

…e to

TYPE: bug fix

KEYWORDS: syntax

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Wrong Fortran syntax most likely being corrected by standard.exe

Solution:
Fix the syntax error

LIST OF MODIFIED FILES:
M dyn_em/module_first_rk_step_part1.F

RELEASE NOTE:
Bug fix for erroneous syntax in dyn_em/module_first_rk_step_part1.F.

…on (wrf-model#2000)

TYPE:bug fix

KEYWORDS: racm_soa_vbs_het_kpp, aerosols

SOURCE: Sergey Osipov (KAUST)

DESCRIPTION OF CHANGES:
Problem:
The bug was introduced after splitting chem_opt 100 and 106. Currently, the chemistry initialization always calls for module_aerosol_soa_vbs routine, leaving the module_aerosol_soa_vbs_HET and corresponding data constants unitialized. As a result, aerosol concentrations are set to 0 after the first time integration (10**-16).

To verify the bug fix, initialize WRF-Chem with non-trivial IC and save the next time step into nc. Check that values are non-trivial (e.g., so4aj, soila).

Solution:
Differentiate between module_aerosol_soa_vbs and module_aerosol_soa_vbs_het initialization routines

LIST OF MODIFIED FILES:
M    Registry/registry.chem
M    chem/chemics_init.F
M    chem/module_aerosols_soa_vbs_het.F

TESTS CONDUCTED: 
- The Jenkins tests are all passing.

RELEASE NOTE: This PR fixes a bug introduced after splitting chem_opt 100 and 106, which left  the module_aerosol_soa_vbs_HET and corresponding data  uninitialized.

TYPE: bug fix

KEYWORDS: compilation, Cygwin, doc files

SOURCE:  Daniel Wesloh (Penn State)

DESCRIPTION OF CHANGES:
Problem:
Compiling WRF failed on Cygwin due to lack of netCDF4

Solution:
Match assumptions about `USENETCDFPAR` (wrf-model#1743 would also fix this) and pass flags to allow legacy Fortran constructs (disallowed by default with GCC 10)

ISSUE: For use when this PR closes an issue.
Fixes wrf-model#1271

LIST OF MODIFIED FILES: 
M       configure
M       doc/README.cygwin.md
M       doc/README.netcdf4par

TESTS CONDUCTED: 
1. Checked whether model compiles on Cygwin in #1
2. The Jenkins tests have passed.

RELEASE NOTE: Fix compilation on Cygwin.

…istributed urban aerodynamic parameters (wrf-model#1986)

TYPE: new feature

KEYWORDS: SLUCM, urban parameters, anthropogenic heat

SOURCE: Do Ngoc Khanh (Tokyo Institute of Technology)

DESCRIPTION OF CHANGES:
This PR adds a new feature to WRF SLUCM by allowing consideration of spatially varying global distributed urban parameters and spatially hourly monthly varying anthropogenic heat.

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M Registry/registry.dimspec
M dyn_em/module_first_rk_step_part1.F
M dyn_em/module_initialize_real.F
M phys/module_pbl_driver.F
M phys/module_physics_init.F
M phys/module_sf_clm.F
M phys/module_sf_noahdrv.F
M phys/module_sf_urban.F
M phys/module_surface_driver.F
M phys/noahmp
M share/output_wrf.F

TESTS CONDUCTED:

- The modification has been tested and used in previous publications.
Initial development: Varquez, A. C. G., Nakayoshi, M., & Kanda, M. (2015). The effects of highly detailed urban roughness parameters on a sea-breeze numerical simulation. Boundary-layer meteorology, 154, 449-469. https://doi.org/10.1007/s10546-014-9985-4
Global extension: Khanh, D. N., Varquez, A. C., & Kanda, M. (2023). Impact of urbanization on exposure to extreme warming in megacities. Heliyon, 9, e15511. https://doi.org/10.1016/j.heliyon.2023.e15511
- The Jenkins tests are all passing.

RELEASE NOTE: This modification adds two options (use_distributed_aerodynamics and distributed_ahe_opt) to WRF SLUCM (sf_urban_physics = 1) so that spatially varying urban morphological parameters (building height, plan area index, frontal area index, roughness length for momentum, and displacement height) can be considered.

There might be more I wanted to add, but I don't remember.
I'll have to add those the way I did the first time,
compiling with -Werror until it works.
This pass is almost exclusively focused on the registry.
I'll have a few more for Fortran once I figure out how.

Inspiration: registry was segfaulting, so I tried fixing the warnings
in case it was one of those.  It didn't work, but it's worth doing
regardless.

Change compile flags back to what they were before.

Guard io.h #include to avoid Linux compilation failures.

Given how much space this provides at the moment, this had better not
run over.

Most likely the better solution is to look up functions
to copy or delete files directly.
I'm not sure where to look for those,
but I'm pretty sure they're not in the C standard.

I pushed it to another branch, so a PR version can get some eyes on it.

external/RSL_LITE implements these as int, so they need to be declared with int returns, not void.

Not quite all of them yet, but there's only one other, that one
without an existing named constant.

EDIT: There's about seventy left: I'll have to go through those again.

I think there's a way to pass this as a parameter to snprintf instead, but I don't remember what that is at the moment.

I looked up how to do this.  Apparently you just stick a star for the width and put the variable with the width before the variable you want to have that width.

grep -E -e '\[[[:digit:]]{2,}\]' *.[CcHhFf]*

Lots of unused variables, but I should be able to leave those for a bit.
Unused parameters would be a pain, so I'm leaving those.

…rf-model#2008)

TYPE:  enhancement

KEYWORDS: chem, KPP, configure_kpp, Derecho

SOURCE: internal

DESCRIPTION OF CHANGES: 
Problem: KPP would not compile on Derecho due to name differences in libfl: only libfl.so exists, not libfl.a.

Solution:
Add flag to search for alternative name, libfl.so.

LIST OF MODIFIED FILES: 

M chem/KPP/configure_kpp

TESTS CONDUCTED: 
- Compiles with old intel compilers with libfl.a and compiles on Derecho with libfl.so
- It passes regression tests.

RELEASE NOTE: KPP configure option for alternative libfl name, libfl.so, in addition to libfl.a.

TYPE: new feature

KEYWORDS: CMake, build, make

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current WRF build system is fragile with many pitfalls making it difficult for users to build & add to it without perpetuating existing problems. Many options exist across various layers of files, languages, and option control-flow.

Solution:
*This requires CMake version 3.20 or newer*
A redesign of the build system from the ground up, maintaining the interfacing feel and knowledge accumulated in `arch/configure.defaults`. Condense option selection and control to single locations and as best as possible reduce the complexity of this control.

This will be a work in progress as gaps are identified in reproducing the full functionality of the makefile build system. Currently only `em_real` and `em_ideal` have limited supported


Brief how to use:
As this is a work in progress, the original `configure` and `compile` scripts have been left as-is. Alongside them are now `configure_new` and `compile_new` which walk a user through a slightly similar experience of configuring & compiling WRF.

A simple usage example would be:
```bash
# Ensure you have cmake 3.20+ and configuration environment set up
./configure_new
# Follow prompts to select configuration
./compile_new [-j N]
```

Notable differences are :
* Submodule code must be checked out beforehand and is not checked out during the compile process
* Stanzas presented to a user are only those for which the compiler exists in the current environment
* `!!` warnings appear for subconfigurations (MPI) that would not be supported in the current environment
* DM/SM selection is now done after selecting a base configuration rather than an individual configuration # within a family of compilers
* Compilation via `compile_new` does not take target to build as an argument - parallel `-j N` jobs still supported
* Users do not need to set `NETCDF` or `LD_LIBRARY_PATH` variables
* Base binaries do not have `.exe` extension, but symlinks are provided
* Binaries, test setups, and everything else generated from compilation is copy-placed (not softlinked) to a separate location - default is `./install`. This means the equivalent `test/em_real/wrf.exe` is now at `install/test/em_real/wrf.exe`


LIST OF MODIFIED FILES: 
A       CMakeLists.txt
A       arch/configure_reader.py
A       chem/CMakeLists.txt
A       cleanCMake.sh
A       cmake/c_preproc.cmake
A       cmake/confcheck.cmake
A       cmake/gitinfo.cmake
A       cmake/m4_preproc.cmake
A       cmake/modules/FindJasper.cmake
A       cmake/modules/FindRPC.cmake
A       cmake/modules/FindnetCDF-Fortran.cmake
A       cmake/modules/FindnetCDF.cmake
A       cmake/modules/FindpnetCDF.cmake
A       cmake/printOption.cmake
A       cmake/target_copy.cmake
A       cmake/template/WRFConfig.cmake.in
A       cmake/template/arch_config.cmake
A       cmake/template/commit_decl.cmake
A       cmake/wrf_case_setup.cmake
A       cmake/wrf_get_version.cmake
A       compile_new
A       confcheck/CMakeLists.txt
A       configure_new
A       dyn_em/CMakeLists.txt
A       external/CMakeLists.txt
A       external/RSL_LITE/CMakeLists.txt
A       external/atm_ocn/CMakeLists.txt
A       external/esmf_time_f90/CMakeLists.txt
A       external/fftpack/fftpack5/CMakeLists.txt
A       external/io_adios2/CMakeLists.txt
A       external/io_esmf/CMakeLists.txt
A       external/io_grib1/CMakeLists.txt
A       external/io_grib1/MEL_grib1/CMakeLists.txt
A       external/io_grib1/WGRIB/CMakeLists.txt
A       external/io_grib1/grib1_util/CMakeLists.txt
A       external/io_grib2/CMakeLists.txt
A       external/io_grib2/bacio-1.3/CMakeLists.txt
A       external/io_grib2/g2lib/CMakeLists.txt
A       external/io_grib2/g2lib/utest/CMakeLists.txt
A       external/io_grib_share/CMakeLists.txt
A       external/io_int/CMakeLists.txt
A       external/io_netcdf/CMakeLists.txt
A       external/io_netcdfpar/CMakeLists.txt
A       external/io_phdf5/CMakeLists.txt
A       external/io_pio/CMakeLists.txt
A       external/io_pnetcdf/CMakeLists.txt
A       external/ioapi_share/CMakeLists.txt
A       frame/CMakeLists.txt
A       inc/CMakeLists.txt
A       main/CMakeLists.txt
A       phys/CMakeLists.txt
A       share/CMakeLists.txt
A       test/em_b_wave/CMakeLists.txt
A       test/em_convrad/CMakeLists.txt
A       test/em_fire/CMakeLists.txt
A       test/em_grav2d_x/CMakeLists.txt
A       test/em_heldsuarez/CMakeLists.txt
A       test/em_hill2d_x/CMakeLists.txt
A       test/em_les/CMakeLists.txt
A       test/em_quarter_ss/CMakeLists.txt
A       test/em_real/CMakeLists.txt
A       test/em_scm_xy/CMakeLists.txt
A       test/em_seabreeze2d_x/CMakeLists.txt
A       test/em_squall2d_x/CMakeLists.txt
A       test/em_squall2d_y/CMakeLists.txt
A       test/em_tropical_cyclone/CMakeLists.txt
A       tools/CMakeLists.txt
A       tools/CodeBase/CMakeLists.txt
A       doc/README.cmake_build
M       tools/fseek_test.c
M       README
M       arch/configure.defaults


- Modified file include an adjustment to a compile test to allow the test to be conducted in an out-of-source build manner as prescribed by CMake. Default logic of this test to still test on the existence of `Makefile`

TESTS CONDUCTED: 
1. In various instances this build is faster and more reliable with meaningful diagnostics when errors occur

RELEASE NOTE: 
Introduction of a CMake build system for em_real and em_ideal

I wanted to make it a short to save space in the strings based on this, but given the push to optimize for clarity that's less relevant.

wrf-model#1942)

TYPE: bug fix

KEYWORDS: Missing/Wrong Prototypes in C code, WRF-Chem

SOURCE: Changgui Lin

DESCRIPTION OF CHANGES:
Problem:
Problem: Most C code written long ago. No prototypes were used. See PR#1823. And, this pr is kind of an extension to PR#1823 addressing the same issue for building WRF-chem.

Solution:
Add missing prototypes; rearrange function order to support new Intel oneAPI compiler

RELEASE NOTE: This PR fixed missing and/or wrong prototypes in C code to support successful compilation of WRF-Chem when using the Intel oneAPI compiler ifx/icx.

This PR fixes 2 issues from the original PR#1986: 1. FRC_URB2D declaration for mosaic option; and 2. AHE option 2 should be added before PBL physics is called. This PR also removes a few un-used variables in surface_driver.

LIST OF MODIFIED FILES:
M       dyn_em/module_first_rk_step_part1.F
M       phys/module_pbl_driver.F
M       phys/module_sf_noahdrv.F
M       phys/module_surface_driver.F

TESTS CONDUCTED: 
The Jenkins tests are all passing.

TYPE: enhancement

KEYWORDS: cmake, diffwrf

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
New CMake build did not create binaries for io_* `diffwrf`

Solution:
Slight restructure of certain targets to allow for easy creation of the diffwrf executables. Since previously all `diffwrf` binaries were named the same, to house them int the same `install/bin/` location they have been prefix with the type of io or shorthand of that option ( io_int -> `diffwrf_int`, io_netcdf -> `diffwrf_nc`, io_netcdfpar -> `diffwrf_ncpar` ). 

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       external/io_int/CMakeLists.txt
M       external/io_netcdf/CMakeLists.txt
M       external/io_netcdfpar/CMakeLists.txt

TESTS CONDUCTED: 
1. Diffwrf execs should now be located in cmake install location

RELEASE NOTE: 
CMake build of diffwrf binaries

…for scalar/chem/tracer (wrf-model#2010)

TYPE:  bug fix

KEYWORDS: mp_zero_out

SOURCE: Ted Mansell (NOAA)

DESCRIPTION OF CHANGES:
This fixes the side-effect of mp_zero_out being applied not only to the moist array, but also to the scalar/chem/tracer arrays using the same threshold. This behavior would be unexpected from the documentation (readme) which indicated that only mixing ratios were affected.  This PR restricts mp_zero_out to the moist array and adds a separate mp_zero_out_all flag to apply it to all the arrays in the off chance that somebody needs to replicate the previous behavior.

ISSUE: Addresses wrf-model#2007

LIST OF MODIFIED FILES: 
M  Registry/Registry.EM_COMMON 
M  dyn_em/solve_em.F 
M  run/README.namelist
M  wrftladj/solve_em_ad.F
M  wrftladj/solve_em_tl.F

TESTS CONDUCTED: 
The Jenkins tests have passed.

RELEASE NOTE: The behavior of the  mp_zero_out flag was changed affect only the 'moist' array, whereas previously it also caused the scalar/chem/tracer arrays to also be set to zero for values below threshold. Now there is a separate flag (mp_zero_out_all) if one wishes to reproduce the old behavior.

…f-model#2015)

TYPE: enhancement

KEYWORDS: auto_levels_opt, dzbot, dzstretch

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Lack of information in the standard output when running real.exe using auto_levels_opt = 2.

Solution:
Adds print for parameters used to define vertical levels.

LIST OF MODIFIED FILES: 
M     dyn_em/module_initialize_real.F

TESTS CONDUCTED: 
1. Now print like the following is added to output from running real.exe:
   p_top =    1000. Pa, dzbot =   30.0 m, dzstretch_s/u =   1.20  1.02
2. The Jenkins tests are all passing.

RELEASE NOTE: This PR adds a print for parameters used when running real.exe using auto_levels_opt = 2 option, which is the default.

…warnings-registry

Fix merge conflicts.

I made nChmOpts a short int to keep buffer size down.
Given the change to named constants, this is likely irrelevant.

On the other hand, it may currently max out at five.